One or more aspects of the present invention relate in general to data processing systems, and in particular, to a software version management system.
Firmware updates changing functionality, which generally is realized by software updates, are widely used in computing systems. Most systems can apply updates only in inactive state, problematic in enterprise environments, where system downtime must be minimized. Specially structured applications may continue to operate with special hardware support while their firmware image is being updated, restricting the duration of service interruption to application restart time—considerably below that of firmware updates. Substantially similar preparation allows updates to preserve any application data even if applications themselves are updated. The combination of these capabilities, known as concurrent update (“CU”), is used in high-availability systems such as mainframes.
State-of-the-art, high-availability computing systems may support the capability to upgrade firmware of system components while the previously loaded versions remain operational, and restart applications only after the update completes. Applications designed to support CU will recognize and work with any persistent data created by previously created firmware, to prevent data loss during the update.
In most current CU-capable systems, the CU-compatibility of multiple firmware revisions is a manually maintained database, embedded directly into host drivers. Annotations designating pairs of firmware revisions as CU-capable—or the opposite, labeling them explicitly as disruptive, warning about application-visible loss of service/data—are considered a property of host drivers, and are maintained as part of host driver firmware. In current systems, host drivers themselves tend to maintain their firmware-image repositories, therefore the close connection is consistent with overall architecture. While this method has advantages—such as the tight integration, and possible optimizations due to data locality—the currently used method does not easily scale to multi-vendor scenarios. Similarly, when newer firmware revisions are introduced, their implied CU-compatibility prompts an update of the corresponding host drivers.
In U.S. Pat. No. 7,383,541 B1, which is hereby incorporated herein by reference in its entirety, a method is disclosed for providing continued correct interoperation of computer software implementations even when the versions of the implementations differ, particularly providing interoperation of a first execution image of a first version and a second execution image of a second version. A compatibility matrix specifies whether the versions are compatible, base-level compatible, or incompatible. The compatibility matrix comprises a sparse table that stores a compatibility indicator for all permutations of a plurality of versions of a network operating system. As part of initialization of a system that includes the first execution image and second execution image, version information for the execution images is determined. An entry in the compatibility matrix corresponding to the versions is identified. The execution images are operated in a fully synchronized state when the identified entry of the compatibility matrix specifies that the versions are either compatible or base-level compatible. Individual components of the execution images interoperate according to the results of individual session negotiations. If the versions are incompatible, an alternative redundancy operation mode may be used. Embodiments provide for negotiation of compatible message versions and capabilities among peer components or clients of the execution images as source information to generate the compatibility matrix.